Developers.IO 2017セッション「実案件で見るデータ分析用AWS基盤の構築方法」を発表しました #cmdevio2017

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「実案件で見るデータ分析用AWS基盤の構築方法」を発表しました。

発表スライド

セッション内容

本セッションでは、私が所属しているインテグレーション(DI)部で経験した案件を元に、

• データ分析基盤の色々
• そこから得たノウハウ
• 基盤構築後発生した問題とその解決
• 今後導入したいAWSサービス

をお伝えしました。以下、詳細です。

データ分析基盤の色々

今までに関わってきた主な案件のパターンを紹介します。

• ログデータ分析
  • 基幹システムのデータをRedshiftに格納しBI参照
    基幹システムのデータをCSVやTSVのようなテキスト形式に変換してもらい、S3に格納する。それをEC2インスタンス上で動作させるバッチプログラムでRedshiftへロード、加工する。ロードされたRedshift上のデータはBIシステムで検索データとして利用される、という構成です。
  • S3のデータをEMRで集計し、Redshiftに格納
    単純なETL処理によるバッチでは間に合わない位の大量データを扱う例も増えてきました。
    この構成では、機械が吐き出す大量のデータを一旦EMRで集計し、結果をRedshiftに格納するという方法を取っています。
    また、特徴的な構成として、集計の指示を出しているのがAlteryxを使っているところです。これは従来HiveQLを使っていた所に、もっと簡単に操作/編集できるツールとして入れたものです。集計作業のフローをビジュアル化することが出来るようになっています。
  • Auroraのデータを直接集計し、別システムに提供
    Webシステムの一部として構成されているデータベースを直接DWHとしても利用するという構成です。
    I/Oが同時並列に多数発生するので、RedshiftではなくAuroraを使用し、WEbシステムとして稼働しつつも、データの集計や参照が行える形にしています。
• 既存DHWリプレース
  他には、従来の大型商用DWHシステムが保守期限切れを迎え、リプレースのタイミングでクラウド化する、というパターンも多く見受けられます。
  クラウド化することで、ハードウェア導入やライセンスなどの初期投資費用を抑え、かつ将来の拡張や廃止にも対応できる柔軟性を必要としているお客様は多くいらっしゃいます。
  ただ、既存の資産があるので直ぐに導入というわけではなく、適切に導入できるかどうか確認するPoC(概念実証)のフェーズを経る事が多いです。

• PoC
  PoCとは、概念実証のこと。構成のイメージを実際に試してみて、実システムに使えるかどうか評価します。
  この中でよくあるのが、既存システムのデータを枝分かれする形でクラウド環境に取り込み、そこで既存/新規BIツールで検索性能を評価する、というスタイルです。

そこから得たノウハウ

• プロジェクトの傾向とポイント

  • 開発3ヶ月、調整3ヶ月位のが多い
    今までの経験からすると、開発は3ヶ月位で済む規模のプロジェクトが多いように思います。
    データ分析基盤は要件を詰めようとしても詰めきれない事が多く、そこは想定を与えて割り切って着手してしまう割り切りが必要です。その代わり、開発後の調整期間を十分に取り、性能要件などを満たす構成に調整する必要があります。
  • 少数で始める
    データ分析基盤の場合、関係者が多くなればなる程分析したいデータ、作成したいダッシュボードは増えます。それにつられて工数も増えるので、初めは少人数で限定されたデータを元に少数のダッシュボードを作り、そこで知見を得られたという成功体験を得ることが優先と考えてください。
  • 予算は柔軟性を持たせる
    言うのは簡単ですが、実際には難しい話だと思います。しかし、実際にどの位リソース(=課金)が必要になるのかはデータ量、処理の複雑さ等が理由でやってみないとわからないということもあります。可能であれば予算の確保だけはしておいて、実際に払ったのは想定より少なかった、位の余裕があった方が良いです。
• 「データレイク」構想
  従来のDWHでは、13ヶ月を迎えた過去データは消去することが多いと思いますが、それはほとんどの場合、ストレージのサイズ制限によるものです。クラウド環境では、過去データは必要な分だけ(課金はありますが)いくらでも保存しておくことができます。
  S3へデータを保存する場合、フォルダの切り方はテーブル名-日付が今のところ無難だと考えています。というのも、実案件ではバッチ処理のリトライとして「テーブルxxの直近3日分を再ロード」のような用件が多いからです。前方一致で拾いやすくなります。
  また、ファイルはCSVよりもタブ区切りのTSVの方がトラブルが少ないです。

• RDB or EMR

  • データ量で判断する
    処理対象のデータ量がRDBのストレージに収まらないような場合はEMRを選択する、という判断があります。
  • リアルタイム性で判断する
    一般にEMRでの処理はバッチ系なので、リアルタイムの問合せが必要な場合はRDBにする、という判断が良いと思います。
  • 関係者のスキルセットで判断する
    システム納入先の企業がメンテナンスを担当する事もよくあります。その際にはメンテナンスを担当する人員が、どの技術に詳しいかを踏まえておく必要があります。
• Redshift or Aurora 最近、DWHとしてRedshiftにするかAuroraにするかの選択が必要になる状況が増えてきました。
  • 同時アクセス数で判断する
    Redshiftは元々の設計上、同時に多数のクエリを処理できるように作られていません。従って同時クエリ発行数が多い場合は、Auroraを選択した方が良い場合があります。
  • クエリの特性で判断する
    Redshiftはカラム型なので、特定カラムの抽出と集計は高速に実行できます。一方、Auroraはインデックスを持つことができるので、行単位のアクセスは高速に実行できます。
  • 可用性用件で判断する
    RedshiftはマルチAZ構成を取ることができないので、あまりないと思いますがダウンタイムを極小化する目的ならばAuroraを選択する可能性もあります。
• ETL or ELT
  • 現在のところは「ELT」
    ETLの場合、中間の加工処理を行う場所を別に用意する必要があり、仕組みが複雑になったり利用料金が増えたりということが発生します。ELTだとDWHの中で、テーブルにSQLを実行させるだけなのでシンプルに構成することができます。
  • 今後は「ETL」へ回帰の兆し
    しかし、システムが大規模になりDWHへの負担が大きくなると、中間の加工処理をDWHの中で回すことが難しくなってきます。そこで再び中間の加工処理をDWHから外に出す動きも始まっています。
    参考：Amazon Redshiftへ継続的にデータをロードする際に気をつけること | クックパッド開発者ブログ
    今後は、Hadoop基盤で一旦集計した後、RDBへロードするというハイブリッドな構成になるのではと考えています。
• ETL(ELT)処理
  よく「ETLツールはどれが良いですか」と聞かれることがありますが、どの要件に対しても万能なものは今のところ無いという見解です。
  機能的には商用製品に素晴らしいものが沢山あるのですが、DWHをクラウド化したことでコストダウンすると、どうしても相対的にETLツールが「高い」印象を持たれてしまうのが現状です。
  現在は、お客様がメンテナンスされる事を考慮に入れて、それぞれのスキルセットに応じた技術で実装することが多いです。

基盤構築後発生した問題とその解決

• 主には「性能問題」 データ分析基盤を開発した後発生する問題として一番多いのは、検索やバッチ処理が思った速度出ないという性能問題です。
  これは多くの場合、想定していたリソース構成が実際の速度要件より(予算の都合などで)小さかったことが原因です。
  結果としてスケールアップやスケールアウトで対応する事になります。

• クラウド流、性能改善の考え方
  一般的には、チューニングを「リソースはそのままで、性能を最大限に引き出す」と考えがちです。しかし、クラウド環境では「リソースを変える」ことができます。そこで先に期間限定でリソースを増強し、目的の速度が得られるリソースを求めます。これは試行錯誤が不要なので、直ぐに結果を得ることができます。その上で発生した余裕時間でテーブル設計などを見直すなどのいわゆる一般的なチューニングを実施します。そして処理を高速化できたところでリソースを減らし、目標性能をクリアしつつ、一番低いコストで運用できるポイントを探ります。このようにして短時間にリソースを含めた性能改善を行うやり方を推奨しています。

• チューニングより構成変更
  今までの経験上、例外はあるものの大体の処理はリソースと処理速度が比例しています。従って細かい設定変更や調整で時間を掛けるよりも、力づくで性能を上げる方が確実に結果を得られます。この性能改善の考え方は、クラウド流として押さえておく必要があります。

• Redshift固有のチューニング
  とは言え、チューニングを全くしない訳ではありません。例えばRedshiftの場合、以下のポイントが挙げられます。

  • データ圧縮
    データは圧縮しておきましょう。最低限COPYコマンドで選択する自動圧縮でも構いません。
  • ソートキーの非圧縮
    逆に、ソートキーになるカラムは圧縮しない方が良いです。なぜならば多数のソートキーを1つのブロックに圧縮してして格納してしまうことで、不要なデータを読み取らざるを得なくなるからです。
  • JOINを考慮した分散キーの設定
    JOINの際にノード間のデータ再分散が発生すると、性能はだいぶ落ちます。再分散が起きないように、同じJOINのキーを持つデータは同じノードに存在するような設計にしておきます。小さなデータはALLの設定にして全ノードに配置するアイデアがあります。

他にもRedshift固有のチューニングポイントはあります。下記リンクが参考になります。

• クエリパフォーマンスのチューニング | Amazon Redshiftデータベース開発者ガイド
• Amazon Redshiftのパフォーマンスチューニング(pdf) | AWS Summit 2014
• Amazon Redshift クエリパフォーマンスチューニング ベストプラクティスを読んでみた | Developers.IO

今後導入したいAWSサービス

今後、データ分析基盤で導入したい期待のサービスを紹介します。

• Amazon Athena S3上のファイルにテーブル定義を与えて、直接SQLで問い合わせできるようになるサービスです。
  テーブル定義の設定は必要ですが、データのロード作業が不要です。
  問合せの結果得られるデータ毎の従量課金です。
  現在のところ、リソースに制限(問合せ同時5、処理時間30分まで)があるので、長時間掛かる処理は不向きです。

• Redshift Spectrum S3上のファイルを、Redshiftのテーブルとして検索できるようになる機能です。
  Athenaによく似ていますが、クライアントの接続先をRedshiftに一本化することができます。
  変則的な使い方としては、従来では不可能だった2つのRedshiftクラスタ間で同じテーブルのデータ(実体はS3上のファイル)を共有する構成も可能です。

*AWS Glue フルマネージドのETLサービスとして期待です。詳細は下記を参照下さい。 * Glue – 特集カテゴリー – | Developers.IO

さいごに

DI部が経験した内容をお伝えしました。
引き続きデータインテグレーション部では、データ分析基盤の構築に取り組んでいきます。